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AMENDMENTS TO THE SPECIFICATION 

Please amend the specification as follows: 

Please replace paragraph [0003] with the following amended paragraph. 

[0003] In a computer system that includes an Itanium® Processor Family (IPF) 
processing chip, the processors are controlled by the operating system. Moreover, the processors 
cannot be currently removed from the control of the operating system according to the current 
standard and the operating system protocols. IPF chips are produced by Intel®. 

Please replace paragraph [0004] with the following amended paragraph. 

[0004] FIGURE 1 depicts a block diagram of a firmware model 1 00 for an IPF system. 
The firmware has three components that separate the operating system (OS) 101 from the 
processors 102 and the platform 103. The firmware, in general, isolates the OS 101 and other 
higher level software (not shown) from implementation differences in the processors 102 and the 
platform 103. The platform 103 includes all of the non-processor hardware. One firmware is the 
processor abstraction layer (PAL) 104. This layer includes processor implementation specific 
features and is part of the Itanium® processor architecture. PAL 104 operates independently of 
the number of processors. Another firmware is the platform/system abstraction layer (SAL) 105. 
SAL 105 includes the platform specific features. The last firmware is the extensible firmware 
interface (EFI) 106. This layer is the platform binding specification layer that provides a legacy- 
free application programming interface (API) to the operating system. PAL 104, SAL 105, and 
EFI 106 together provide system initialization and boot, machine check abort (MCA) handling, 
platform management interrupt (PMI) handling, and other processor and system functions which 
would vary between implementations. Additional information on IPF systems may be found in 
Intel® manuals "Intel® Itanium® Architecture Software Developer's Manual," Vol. 2, 'System 
Architecture, ' Rev. 2.0, Doc. No. 245318-003, December 2001, and Doc. No. 248699-005, 
Specification Updated August 2001, and "Itanium® Processor Family System Abstraction Layer 
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Specification," Doc. No. 245359-005, July 2001, both of which are incorporated herein by 
reference. 

Please replace paragraph [0013] with the following amended paragraph. 

[0013] Also note that there may be no time limit on how long the firmware may 
borrow the processor. Thus, if the OS has chosen to support the borrow event, and allow the 
firmware to borrow the processor, it is for 'as long as needed'. If the OS does not grant 
unconstrained use of the processor, then the semantics could differ by OS version. For example, 
WINDOWS operating system may have one time limit, while HPUX operating system m ay have 
another, etc. The OS may be written to tolerate the unconstrained use of the processor. 
Therefore, even if the firmware has a bug and never returns the processor to the OS, the OS will 
not fail fatally. The intentional omission of a time limit also minimizes surprise because of the 
clear semantics dividing the use interval between OS and FW and the unambiguous transfer of 
ownership of the processor from OS to FW and back to OS. 

Please replace paragraph [0018] with the following amended paragraph. 

[0018] If the OS grants the request, the OS places the processor into the Ready-to- 
Borrow state, as shown in step 204. This state is further described with regards to FIGURE 3. 
Before the firmware uses the borrowed processor in step 204, the processor receives the PMI 
event in step 208. Before receiving the PMI event, the targeted processor may be executing 
kernel code, even if the processor is in the ready-to-borrow state (which may be a do-nothing 
loop). After receiving the PMI event, the processor begins executing firmware. Note that the 
IPF architecture causes the processor to execute some PAL firmware before the SAL firmware 
execution. For related information on this action, see Figures 1 1-2 and 11-3, along with the 
accompanying text, as well as chapter 5, of the "Intel® Itanium® Architecture Software 
Developer's Manual", which is hereby incorporated by reference. Note that from the PAL 
layer's perspective, the processor is merely passing through to the SAL layer. Moreover, the 
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PAL layer may have no concept of the goal-oriented purpose of PMI events, which by 
architecture, are platform specific. 

Please replace paragraph [0018] with the following amended paragraph. 

[0025] The transition from the active state 301 to the ready-to-borrow state 306 is 
referred to as the deactivate transition 313. This transition is initiated by the OS, whereby the 
processor yields control to some other policy agency, e.g. the firmware. Note that the deactivate 
transition may be used to switch control to other entities, e.g. in IPF systems, the deactivate 
transition is used by the OS to move a processor into a low-power state using architected or 
implementation specific transitions supported by the IPF processor. See section 1 1 .6 of the 
Intel® Itanium™® Architecture Software Developer's Manual Vol. 2 rev 2.0. System 
Architecture, which is hereby incorporated herein by reference. The transition from the ready- 
to-return state 308 to the active state 301 is referred to as the reactivate transition 3 14. This 
transition moves the processor from the Ready-to-Return state back into the Active state where 
the operating system regains full control of the processor resource. The transition from the 
ready-to-borrow state 306 to the borrowed state 307 is referred to as PMI transition 315. This 
transition may be initiated by the OS, and moves the processor into the control of the firmware. 
In IPF platforms, the firmware most likely to take control of the processor is the system 
abstraction layer (SAL) firmware, thus transition 315 may be referred to as SAL PMI. 

Please replace paragraph [0040] with the following amended paragraph. 

[0040] The platform 400 may include processor abstraction layer (PAL) firmware 409. 
The layer contains processor dependent initialization firmware that is typically developed by the 
processor vendor. The PAL layer receives the PMI event 41 8 from the processor CPU, and 
passes the event 419 on to the SAL layer 408. Note that the PAL firmware first gains control 
(begins executing) in response to PMI events accepted by the CPU. For further information on 
the interaction between the PAL and SAL firmware layers, see chapters 5 and 1 1 of the "Intel® 
Itanium® Architecture Software Developer's Manual", which is hereby incorporated by 
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reference. The sequence is that, first, the OS causes an inter-processor interrupt using PMI level 
1, 2 or 3 that is to be sent to the targeted processor. This is architected by hardware. Next, the 
interrupt causes the target processor to switch to physical mode and branch into PAL. This is 
architected by hardware. Next, the PAL executes and does minimal state saving according to the 
SAL-PAL interface definitions for the system. Next, the PAL transfers control into SAL, if the 
SAL had previously registered its PMI entry point for that CPU. This is architected by firmware. 
Next, the SAL executes on the borrowed processor, and when complete, the SAL invokes the 
PAL ReturnFromPMI function. This is architected in firmware. Next, the PAL returns to the 
interrupted instruction inside the OS. This is architected in hardware and firmware. At this 
point, the OS handler 407 notices the processor is back and reactivates the processor to resume 
using the CPU normally. 

Please replace paragraph [0040] with the following amended paragraph. 

[0042] The platform may include platform hardware 411, which is the hardware of the 
computer system, including the processor 410. Note that there may be one or more processors. 
The processor would receive the PMI message 417, and branch to the PAL PMI entry in the PAL 
layer. For more information on this action, see Figures 1 1-2 and 1 1-3, along with the 
accompanying text, as well as section 1 1.5 of the "Intel® Itanium® Architecture Software 
Developer's Manual", which is hereby incorporated by reference. 
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